fix: break CurlHandle reference cycle leaking connections - #22

Adapter::call() built a new Utopia\Fetch\Client for every request. Each
one leaks its cURL handle and the connection behind it through a closure
reference cycle (utopia-php/fetch#22), so a long-running process grows
without bound in native memory that PHP's memory_limit cannot see.

In production this OOM-killed task-billing-payments: the pod idles at
~330MB of its 512Mi limit, and the daily due-invoice batch (~1000
invoices, several Stripe calls each) added ~200MB in four minutes and
crossed the limit. The PHP heap stayed flat throughout, so nothing was
logged before the kernel killed it.

Swap to utopia-php/client, which keeps one cURL handle for the lifetime
of the adapter and reuses its connection. Measured over 400 identical
requests:

    before   +800 fds, +21 MB RSS
    after      +0 fds, +64 kB RSS

The client is injected through the constructor and readonly, so the
transport is the caller's to choose: a pool for coroutine contexts, a
retry decorator, its own timeouts, or a double under test. The adapter
holds one request factory for the same reason it holds one client.

Two consequences of the swap:

- utopia-php/client requires PHP 8.5, so pay does too. The CI matrix
  drops 8.0-8.3.
- The multipart/form-data branch and its flatten() helper are removed.
  No adapter used them, and the new request factory models multipart as
  typed parts rather than a flattened array, so a future adapter should
  build them through that instead of resurrecting the old shape.

GET params move from the request body to the query string, which is
where they belong. Stripe accepts either — verified against the live API
that a created[gt] filter is honoured both ways — so this changes the
wire format, not behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adapter::call() built a new Utopia\Fetch\Client for every request. Each
one leaks its cURL handle and the connection behind it through a closure
reference cycle (utopia-php/fetch#22), so a long-running process grows
without bound in native memory that PHP's memory_limit cannot see.

In production this OOM-killed task-billing-payments: the pod idles at
~330MB of its 512Mi limit, and the daily due-invoice batch (~1000
invoices, several Stripe calls each) added ~200MB in four minutes and
crossed the limit. The PHP heap stayed flat throughout, so nothing was
logged before the kernel killed it.

Stripe now builds its requests with utopia-php/psr7's factory and sends
them with a utopia-php/client that keeps one cURL handle for the
lifetime of the adapter. Measured over 400 identical requests:

    before   +800 fds, +21 MB RSS
    after      +0 fds, +48 kB RSS

The client is injected through the constructor and readonly, so the
transport is the caller's to choose: a pool for coroutine contexts, a
retry decorator, its own timeouts, or a double under test.

Adapter::call() and the METHOD_* constants are gone with it. A PSR-18
client and a PSR-17 factory already express "build a request, send it",
so the indirection bought nothing but a second vocabulary for HTTP —
seven of the nine constants had no caller. Adapter goes back to being
the provider contract, with no imports and no transport of its own;
Stripe owns its client because the wire format is its concern, not the
contract's.

Two consequences of the swap:

- utopia-php/client requires PHP 8.5, so pay does too. The CI matrix
  drops 8.0-8.3.
- The multipart/form-data branch and its flatten() helper are removed.
  No adapter used them, and the new request factory models multipart as
  typed parts rather than a flattened array, so a future adapter should
  build them through that instead of resurrecting the old shape.

GET params move from the request body to the query string, which is
where they belong. Stripe accepts either — verified against the live API
that a created[gt] filter is honoured both ways — so this changes the
wire format, not behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>